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What is the Hayes Synchronous Interface? 

The Hayes Synchronous Interface (HSI) is a specification describing the interface 
between two layers of software in a synchronous communications package. One 
layer of software, the "synchronous driver," consists of the routines necessary to 
operate the synchronous communications hardware. The synchronous driver 
services device interrupts and transfers data to and from the hardware using the 
computer's I/O instructions. 

The other layer of software, the "application," transmits and receives messages. HSI 
describes how these messages, and control information, are exchanged between 
the application and the synchronous driver. 
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What is the Hayes Synchronous Driver? 

ciinnnrtinn HSI is the Hayes Synchronous Driver (HSD). HSD is software that 
"eO! ^imeJru^t?e y rvici y ng and other detailed I/O operations necessary to 
ooerate specific hardware, such as the Hayes Smartmodem 2400B, in its synchronous 
mode Its interactions with the main body of the synchronous application software 
conform to the HSI design specification described in this document. The Hayes 
Synchronous Driver therefore bridges the gap between the synchronous application 
software and the Smartmodem 2400B hardware. The Hayes Synchronous Driver can 
be licensed from Hayes Microcomputer Products, Inc., on an annual fee basis by 
software developers. 



Review of Synchronous Concepts and Terminology 

Synchronous communications differ from asynchronous communications in that 
data is organized into messages. In asynchronous communications, data is 
exchanged character-by-character. There is no strict timing relationship between 
the transmission of one character and the next. Start and stop bits must be 
transmitted to announce when each character is transmitted. 
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In synchronous communications, however, data is exchanged in messages. The 
characters which comprise each message are transmitted back-to-back, with no start 
or stop bits. Removing this start bit/stop bit overhead makes synchronous 
communication more efficient than asynchronous communication. Furthermore, 
the message-oriented nature of synchronous communication can be used to greater 
advantage by sophisticated applications (such as office automation) than the more 
primitive character-by-character asynchronous communication. 
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In both synchronous and asynchronous communication, the stream of ones and 
zeros coming in from the communications line must be converted into a stream of 
characters. Various techniques are used to establish the boundaries between the 
characters in the stream of oits. This conversion is almost always carried out by 
specialized hardware in the synchronous or asynchronous communications adapter. 
In addition, synchronous communications convert the stream of characters into 
messages, and various techniques are used to indicate the beginning and end of 
each message. 
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In general, the beginning and end of each synchronous message is indicated by 
protocols which place a special bit pattern or control character at the beginning and 
at the end of the message. Synchronous protocols using control characters are oyte- 
oriented; those using bit patterns (not necessarily corresponding to characters) are 
bit-oriented. Byte-oriented protocols, such as IBM's Binary Synchronous 
Communications (BISYNC), are generally older and being replaced by the more 
modern bit-oriented protocols, such as IBM's Synchronous Data Link Control (SDLC) 
or X.25's High-Level Data Link Control (HDLC). 
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Role of the Synchronous Driver 

The characters-to-messages conversion is carried out jointly between the 
communications interface adapter hardware and the synchronous driver software. 
The responsibility of the synchronous driver software is to: 

1 . Respond to interrupts generated by the adapter using I/O instructions. 

2. Assist the communications interface adapter hardware in characters-to- 
messages conversion. 

3. Accept messages to be transmitted from the application and send it messages 
that nave been received. 
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Recap: What are HSI and HSD? 

This document describes the Hayes Synchronous interface (HSI), a standard way of 
fitting the application and synchronous driver together. HSI is the interface used by 
the Hayes Synchronous Driver (HSD), a complete driver module that supports Hayes 
synchronous devices. The source code for HSD is available for license from Hayes 
Microcomputer Products, Inc., Customer Service group. By following the 
specifications in this document, software developers can write synchronous drivers 
for non-Hayes synchronous devices that support the same application interface as 
HSD. 
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Advantages of Using HSI and HSD 

By using HSI in a synchronous communication software package, compatibility with 
current and future synchronous products from Hayes can be achieved. Hayes has 
made available an HSI-compatible synchronous driver supporting current products 
and will update this driver to support future synchronous products. 

General compatibility with other synchronous hardware devices can be achieved by 
writing or obtaining HSI-compatible synchronous drivers. Since these synchronous 
drivers would share the same application interface, support is added to the 
synchronous communication package without changing the application side of the 
standard interface. 
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OVERVIEW 

HSI consists of three main components: 

1 . Interface Record, or InterfaceRec, a control block shared between the driver 
and the application 

2. Driver Routines, five routines inside the driver that the application calls 

3. Service Routines, five routines inside the application that the driver calls 
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Physically, a synchronous driver (such as HSO) consists of a code segment containing 
the five driver routines, plus a device service routine for each device supported bv 
the driver. ™ 7 



5 Service Routines 

• SignalProc 

• TxCharProc 

• RxCharProc 

• DelayProc 

• Trace Proc 




5 Driver Routines 

• Preprocess 

• StartSync 

• EndSync 

• StartTx 

• UpdateSigs 
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The InterfaceRec 

The InterfaceRec is a control block containing information used to control the 
operation of one synchronous device. If more than one device is being operated 
simultaneously, there would be an InterfaceRec for each one, but each InterfaceRec 
would have the same format. The address of the InterfaceRec is passed as a 
parameter every time a driver routine or service routine is called. It is the 
application's responsibility to allocate memory for the InterfaceRec. 
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Inside the InterfaceRec 



p A detailed breakdown of the InterfaceRec is presented in Appendix A. Some fields 

in the InterfaceRec are controlled by the application, the synchronous driver, or 
1 both. The fields in the InterfaceRec can be divided into five sections: 

m 1. Device Identification 

These fields are set by the application, read by the synchronous driver, and 
m used during set-up to help the driver identify the device it will operate. 

1 2. Synchronous Parameter Selection 

m These fields are also set by the application and read by the synchronous driver 

L They are also used during the set-up phase to establish synchronous protocol 

options. 
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3. Data Exchange Interface 

This section contains fields that are controlled by the synchronous driver, the 
application, or both. These fields are used during active/on-line" operation 
to coordinate the flow of data messages sent back and forth between the 
driver and the application; to control and report the status of the modem 
signal lines; and to report and record error conditions. The data exchange 
interface can be divided into three subsections: receive side, transmit side, 
and modem signals. 

4. Service Routine Add resses 

Five fields are defined in this section, in which the application stores the 
addresses of the five service routines. This is the linkage mechanism by which 
the synchronous driver learns the addresses of the service routines, which are 
essentially subroutines inside the application that the driver may call. 

5. Reserved Areas 

Two 48-byte reserved areas are included in the InterfaceRec: one for the 
synchronous driver's internal use and one for the application to use however it 
wishes. 

The Driver Routines 

The five driver routines, called by the application, are as follows: 

1. Preprocess Called before starting synchronous operation, Preprocess 

identifies the device to be operated and completes driver 
initialization. 

2. StartSync Starts synchronous operation. 

3. EndSync Terminates synchronous operation. 



npi 

ipsi 10 



4. StartTx 



The application calls StartTx to inform the synchronous driver 
that it has a message to transmit. 



UpdateSigs Calling UpdateSigs causes the synchronous driver to update 
the status of the modem signals. 



The Service Routines 

The five service routines, called by the driver, are: 

1. SignalProc 



Part of the signaling mechanism the synchronous driver uses 
to inform the application when certain events occur. 

Used to customize transmitter operation in BISYNC mode. 

Used to customize receiver operation in BISYNC mode. 

Used when a delay is required during termination. 

Part of a simple trace facility useful for debugging driver code. 



In essence, the synchronous driver transmits and receives messages via specific 
hardware and passes these messages to and from the application using a standard 
interface, HSI. Buffers are used to store these messages; a buffer is a reusable block 
of memory large enough to contain an entire message. Usually, one standard 
buffer size is used in a given application. HSI is compatible with any buffer size, up 
to 64K bytes. Each message must be stored in a separate buffer and must fit into a 
single buffer. 
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HSI supports two basic synchronous protocols: SDLC/HDLC and BISYNC. In the case 
of SDLC/HDLC, messages are called frames, so each buffer corresponds to one 
SDLC/HDLC frame. In the case of BISYNC, messages are called blocks, so each buffer 
corresponds to one BISYNC block. 
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What the Synchronous Driver Does 

The synchronous driver performs all interrupt handling and device I/O necessary to 
transmit and receive messages: on the transmit side, it takes da,ta characters from 
the buffers and feeds them to the hardware transmitter; on the receive side, it 
accepts data characters from the hardware receiver and stores them in empty 
buffers. 



What the Application Does 

The application is responsible for buffer allocation and management. In general, 
the application does everything that might involve interacting with the host 
operating system, such as memory allocation and deallocation, and process 
synchronization. When it has a message to transmit, the application stores the 
message in a buffer and passes the buffer to the synchronous driver. The 
application also maintains a queue of messages to be transmitted, if this is desired. 
The synchronous driver signals the application when it has completed message 
transmission; the application may then remove the spent buffer and replace it with 
a buffer containing the next message to transmit. 
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Similarly for the receive side, the application supplies the synchronous driver with 
an empty buffer to receive the next incoming message. When message reception is 
completed, the driver signals the application, which queues the message for 
processing and replaces the full buffer with an empty one. 
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Starting Synchronous Operation 

Calling Preprocess 

An application using HSI first initializes itself, allocating memory for buffers and 
the InterfaceRec. The application fills in a number of InterfaceRec fields, 
including those for device identification and synchronous parameter selection, 
then calls Preprocess. Preprocess identifies the hardware configuration and 
examines the selected synchronous protocol options. It returns a result code to 
the application indicating whether it completed its operations normally or 
whether an error occurred (perhaps a protocol option was selected that the 
hardware being used didn't support). 
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Sometimes synchronous devices have an alternate communications channel or 
method used to exchange control and status information. Preprocess may need 
to interact with the device over that alternate channel to carry out its functions, 
(e.g., the asynchronous command state of the Hayes Smartmodem 2400B). 

In such cases it may be desirable to use a separate driver to operate the alternate 
channel or communication method (e.g., an asynchronous driver for the 
Smartmodem 2400B). HSI allows for this by defining a mechanism by which 
Preprocess can interact with the separate driver. For example, when Preprocess 
passes an AT command to the asynchronous driver, the asynchronous driver 
issues the command, collects the modem's response string, and passes it back to 
Preprocess. 
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Calling StartSync 

When Preprocess returns with an "OK" result code, both the driver and the 
application are completely initialized and ready to go. To actually start 
synchronous operation, the application calls StartSync. The driver takes control 
of the device, installs its interrupt service routine, initializes the device registers 
according to the selected synchronous protocol options, and begins transferring 
data. 









I PI 



A pplication 



Coll StartSync 



•Online 



Sync Driver 



Install Interrupt routine 
Set up deuice registers 



JsP??F 



PBI 



How the Driver Gets Control of the CPU 

After control returns from the StartSync call, the driver gets control of the processor 
again to perform its functions in one of two ways: 

in response to device interrupts, or 

whenever the application calls StartTx to start a transmission or calls 
UpdateSigsto update the modem signals. 
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The driver keeps control as long as it takes to carry out the necessary operations to 
service the interrupt, start the transmission, or update the modem signals. Control 
is then returned to the interrupted process or the caller of the driver procedure. 
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The Signaling Mechanism 

On a number of occasions the driver must interact with the application. For 
example, message reception may have just been completed or a modem signal 
might have changed state. To manage such events, the application must execute 
specialized code. The signaling mechanism enables that code to be executed at the 
right time. 
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When the driver detects one or more events, it constructs a special signal word 
indicating which events have occurred. Before it returns control to the interrupted 
process or the caller of the driver procedure, it calls SignalProc, and passes the signal 
word as a parameter. Inside SignalProc, the application handles each event by 
executing the appropriate code or causing the multitasking system (if one is being 
used) to schedule a high-priority task to handle the event. 




Application 



Decision 
based on 
event 





Interrupt 



or call 
Signal 



Bet"r" 



Sync 
Driver 




pn 




.liR 



|((P9 



mpi 



ipt 



i fpfj 



fW 



GP 



fvHI 



18 



Stopping Synchronous Operation 

When the application is ready to terminate synchronous operation, it calls EndSync, 
causing the driver to turn off the device, remove the interrupt service routine, and 
terminate synchronous operation. The synchronous communication session may be 
restarted by calling StartSync again. Preprocess should not be called again unless a 
new synchronous session (with different parameters) is desired. 
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Stopping and restarting synchronous operation is necessary if the application needs 
to use the device (e.g., a Hayes modem) to perform a short, transient operation, 
such as issuing a status-inquiry AT command. 



Error Handling 

The synchronous driver is responsible for handling all error situations that might 
arise during device operation. An error code field is defined in the InterfaceRec for 
both transmit and receive. When a transmit or receive operation is completed 
(either normally or with an error), an appropriate code is stored in this field to 
indicate the outcome of the operation. In addition, an array of error counters, one 
for each error code for both transmit and receive, is defined in the InterfaceRec. 
The driver automatically maintains these counters, which indicate how many 
transmit and receive errors have occurred. 
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HSI supports both BISYNC and SDLC/HDLC protocols. Support of SDLC/HDLC is 
<" straightforward, as these protocols (essentially identical for our purposes) enjoy 

well-established standards for frame formats, transmission and reception rules, etc. 

Many BISYNC applications, however, use slightly different variations of the basic 
- protocol. Thus, the application must customize the operation of the synchronous 

driver in BISYNC mode according to the BISYNC protocol variant being used. 

This is accomplished through two per-character routines, RxCharProc and 
^ TxCharProc. On the receive side, the driver calls RxCharProc after each character is 

received. Inside RxCharProc, the application examines the characters as they are 
received, and decides to accept them, delete them, or initiate end-of-message 
m processing. On the transmit side, the driver calls TxCharProc just before 

transmitting each character. Inside TxCharProc, the application decides to issue the 
character for transmission, substitute a different character, or insert a new character 
into the message. In general, the application must do more work when BISYNC 
mode is selected instead of SDLC/HDLC. 
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Modem Signal Support 

Modem signals are binary, electronic signals carried between the synchronous 
hardware and the device it is connected to, usually a modem. The use of these 
signals is standardized by the RS-232 specification, but the standard is not adhered 
to precisely by every device. To accommodate nonstandard use of these signals 
(such as occurs in IBM's modems to support Link Problem Determination Aid, LPDA), 
HSI makes few assumptions about the modem signals. 
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Sixteen of the 25 possible modem signals are provided for in a modem signal word 
found in the InterfaceRec, which shows the current status of these signal lines (data, 
clock, and ground signals are omitted). The application can set and test these 
signals individually. The InterfaceRec also contains a word set by the synchronous 
driver, indicating which of the 1 6 signals are actually functional in the device being 
used. 
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HSI specifies the operation of three modem signals: RTS, CTS, and DCD. The 
synchronous driver's transmit routines automatically raise RTS (Request To Send) 
before each transmission, if the application has not programmed this signal high. In 
addition, these routines wait for CTS (Clear To Send) before beginning the 
transmission. An error is generated if CTS is lost during transmission. Similarly, an 
error is generated by the receive routines if DCD (Data Carrier Detect) is not present 
during a receive operation. 

Trace Facility 

HSI provides a simple trace facility, useful for debugging driver code. The TraceProc 
service routine can be used to pass trace information from the synchronous driver to 
the application. The application makes sure that the trace information is displayed 
or printed for the programmer to study. 
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CHAPTER 1-STARTING SYNCHRONOUS OPERATION 

This chapter describes the process of starting synchronous operation using HSI In 
chronological order, it describes the operations the application and the synchronous 
driver must perform. 

Creating the InterfaceRec 

The application is responsible for allocating memory for the InterfaceRec. Using the 
memory management services available through the host operating system and/or 
programming language, a block of memory of the correct size is allocated. The size 
of the InterfaceRec is indicated in Appendix A. After allocating the InterfaceRec 
the application clears the entire block of memory to zeros. 

Next, the application fills in the device qualifier field, DEVQUAL, and the 
synchronous parameter selection fields. The synchronous parameter selection fields 
are discussed in Chapters 2 and 3 on SDLC/HDLC and BISYNC operation, respectively 
The device qualifier field is discussed below. The application also stores the 
addresses of the five service routines in the InterfaceRec fields defined for this 
purpose. 
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Device Qualifiers 

The synchronous driver determines the hardware configuration present, but may 
require assistance to do so. To assist the synchronous driver establish device 
identity, the DEVQU AL field is provided in the InterfaceRec. This 1 6-bit field is not 
defined in detail by HSI, since the information needed by a synchronous driver to 
establish device identity cannot be anticipated. 

To clarify the DEVQUAL concept, consider a synchronous driver for a device such as 
the Hayes Smartmodem 2400 B. This device can be set to one of two possible 
configurations: COM 1 or COM2. It is impossible for the driver to know which COM 
port it must use to access the Smartmodem 2400B; therefore the device qualifier 
field is used to provide this information. DEVQUAL = 1 could be used to indicate 
COM1, and DEVQUAL = 2 to indicate COM2. 
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When. the drivers for several different synchronous devices are packaged in one 
large synchronous driver module (such as HSD), it is not possible through hardware 
alone to determine which synchronous device is present at any given time. 
Therefore, the device qualifier field may be used to indicate which device-specific 
driver will be activated within the large synchronous driver module. 



InterfaceRec 



DEVICEQUAL- 




Devfce X 



i 



Device V 



Device Z 



i 



23 



r 



rap 



Appendix C lists a number of reserved device qualifier values, including those used 
with HSD. As a service to HSD licensees, Hayes is coordinating the assignment of 
additional DEVQUAL values for use with synchronous drivers other than HSD. These 
values will be openly published with the values currently listed in Appendix C. 
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I/O Port and Interrupt Vector 

For some choices of DEVQUAL, the InterfaceRec fields IOPORT and INTVEC must be 
filled in with the I/O port address and interrupt vector number of the hardware in 
use. This step is necessary when these quantities can vary over a relatively wide 
range, according to the position of DIP switches or jumpers on the hardware device. 

The synchronous driver determines whether or not IOPORT and INTVEC is set. If 
IOPORT and INTVEC are not set by the application, the synchronous driver may use 
them to store the I/O port and interrupt vector it chooses. Appendix C details the 
use of IOPORT and INTVEC with current DEVQUAL values. 
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Calling Preprocess 

Having allocated and partially initialized the InterfaceRec, the application next calls 
Preprocess. As with all driver routines and service routines, the address of the 
InterfaceRec is passed as a parameter to Preprocess. Inside Preprocess, the driver 
examines the device qualifier and completely establishes device identity. It also 
looks at the synchronous parameter selections and makes sure that the hardware in 
use supports all of the selected options. Preprocess returns a result code to indicate 
whether or not it detects an error in the selected options, or to invoke the RECALL 
facility. 
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RECALL Facility 

In general, Preprocess does not interact with the synchronous device to perform its 
functions, since the device may be operating in an alternate mode or capability 
which must not be disturbed. However, Preprocess may need to interact with the 
device in order to identify it or preset some of the synchronous protocol options. At 
such times, it is best to use an alternate driver (such as an asynchronous driver) to 
operate the device. To support this type of interaction, the RECALL facility is 
provided. 

The RECALL facility lets Preprocess send a message to the device and receive a reply. 
To use the RECALL facility, Preprocess stores its message (a character string) in the 
InterfaceRec field STRING, then returns to the calling application with the result 
code RECALL When it receives this RECALL result code, the application interacts 
with the alternate driver to communicate the message to the device and collect the 
response. The response, also a character string, is stored back into the STRING field, 
and Preprocess is called again. 

With the Hayes Smartmodem 2400B, asynchronous AT commands must be issued to 
preset some of the synchronous protocol options. Preprocess stores the necessary 
command string in the STRING field and returns RECALL. The application then uses 
an asynchronous driver to issue the command string to the Smartmodem 2400B, 
collects the modem's response characters, and stores them back into the STRING. It 
then recalls Preprocess. This RECALL mechanism may be repeated before Preprocess 
returns a result code indicating that the process is completed, with or without error. 
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Preprocess Result Codes 

Appendix B describes how Preprocess is called and how the result code is returned. 
The following result codes may be returned by Preprocess: 

OK Preprocess operations complete, no error. 

RECALL Application should transmit message in STRING to device, 

store reply back into STRING, and call Preprocess again. 

BADQUAL Driver does not understand the supplied device qualifier. 

BADCALL Preprocess called again; RECALL not activated. 

MODENS Selected SDLC/HDLC or BISYNC mode not supported by device. 

WRAPNS Wrap option (explained in Chapter 2) not supported by device. 

METHDNS Device doesn't support synchronous method implemented by 

the selected driver. 

Calling StartSync 

To actually start synchronous operation, the application calls StartSync. Before 
calling StartSync, the application prepares its side of the data exchange interface 
(see Chapter 2) since data transfer could commence immediately. Inside StartSync, 
the driver takes control of the device, programs its registers for the selected 
synchronous protocol options, installs an interrupt service routine, and begins 
operation. When control returns from StartSync, synchronous communication is 
fully operational. 
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CHAPTER 2--RECEIVING AND TRANSMITTING: SDLC/HDLC 



SDLCandHDLC 

For our purposes, SDLC and HDLC are essentially the same. They share the same 
frame format, flag pattern, and frame check sequence. They both make use of 
techniques such as zero bit insertion and deletion. The differences between SDLC 
and HDLC lie at the level of data link control procedures. They differ in how 
messages relate to each other, not how individual messages are transmitted. Since 
the synchronous driver is concerned only with transmitting and receiving individual 
messages, and not with determining the correct response to a received message, it is 
not aware of the differences between SDLC and HDLC. 
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Frame Format 

SDLC/HDLC messages are called frames. Each frame is stored in a separate buffer 
provided by the application. Frames cannot span buffer boundaries, and the 
maximum buffer size is 64K bytes. HSI assumes that 8-bit characters are being used, 
and provides no support for alternate character sizes. 

The address and control fields of each frame are stored in the buffer as if they were 
data. In general, the synchronous driver does not distinguish between the address, 
control, and information fields of a frame. (An exception is the address detect 
option described later in this chapter.) Flags are not stored in the buffer, nor is the 
Frame Check Sequence (FCS). 
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SDLC Frame Format 
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What the Synchronous Driver Provides 

The synchronous driver (with the hardware device) automatically appends the 
opening and closing flags to transmitted messages, and computes and appends the 
FCS. On the receive side, the opening and closing flags are detected, and the FCS is 
computed and checked. An error is reported if the received FCS is incorrect. Abort 
sequences are properly detected on receive data and properly generated on 
transmit data. Zero-bit insertion on transmit data ana deletion on receive data is 
performed in a manner transparent to the application. 



Synchronous Protocol Options for SDLC/HDLC 

The application must select certain protocol options during set-up (before calling 
Preprocess). To makes its choices, the application sets the InterfaceRec fields (in the 
Synchronous Parameter Selection section) to the appropriate values. The choices 
relevant to SDLC/HDLC mode are as follows: 
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SDLCADDR 

BSCSYNC 
NRZI 

FLAGIDLE 
WRAP 



To select SDLC/HDLC mode, this field is set to 0. Some 
synchronous devices might not support SDLC/HDLC operation; 
in such a case Preprocess would return the result code 
MODENS (Mode Not Supported). 

To enable the address detect option, this field is set to 1 ; 
otherwise, it is set to 0. 

If the address detect option is enabled, only frames whose 
address field matches the programmed station address will be 
received and passed on to the application. Frames with the 
broadcast address FF will also be received. Frames that match 
neither address will be ignored and no error code will be 
generated. Extended address fields are not supported; only 
the first byte of the address field is checked. 

If the address detect option is enabled, the desired station 
address is stored in this field. If the option is not enabled, the 
driver ignores this field. 

The driver ignores this field for SDLC/HDLC mode. 

If Non-Return To Zero Inverted (NRZI) encoding and decoding 
is desired, this field should be set to 1 ; otherwise, it is set to 0. 

If this field is set to 1, the transmitter will send continuous flag 
patterns (01 1 1 1 1 10) when it has no data to transmit. If this 
field is set to 0, the transmitter will send a continuous mark 
level (all ones). 

Some hardware devices have a wrap mode in which transmit 
data is immediately fed back into the receiver for test 
purposes. 
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To select wrap mode, this field is set to 1 ; otherwise, it is set to 
0. If the hardware device in use does not support wrap mode, 
Preprocess will return the result code WRAPNS (Wrap Not 
Supported). If wrap mode is selected, it remains in effect for 
the duration of the synchronous session. To turn wrap mode 
off, a new synchronous session must be started by clearing the 
WRAP field, changing necessary synchronous parameters, and 
calling Preprocess and StartSync again. 
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Start-up Considerations for Receiver 

The application and the synchronous driver go through the following sequence to 
receive incoming data. Before starting synchronous operation, the application 
stores the size of the buffers being used in the field RXBUFSIZ found in the data 
exchange section of the InterfaceRec. The buffer size selection is fixed at this point; 
it may be changed only after terminating synchronous operation. Notice, however, 
that RXBUFSIZ only pertains to the receive side. 

Before starting synchronous operation, the application gets two empty buffers and 
places their addresses in RXBUFand RXNXTBUF. RXBUF points to the buffer which 
will store the next incoming message; RXNXTBUF points to the buffer which will 
store the next message. 
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Receiver Operation: Driver 

When the next message arrives, its characters are stored in sequential positions in 
the buffer pointed to by RXBUF. The driver uses the RXINDEX field to point to the 
next place to store a character in the buffer. 

At the end of the message, the driver stores the number of characters received (the 
final value of RXINDEX) in the field RXCOUNT (the PILEUP error is explained later). 
If an error occurred, it stores an error code in RXERROR and increments the 
corresponding error counter. If no error occurred, the driver stores a zero in 
RXERROR. In preparation for receiving the next message, it then clears RXINDEX 
and transfers the buffer address in RXNXTBUF to RXBUF. Finally, the driver sets 
RXREADY to 1 and sends a signal, RXDONE, to the application. 

The driver sets the flag RXINPROG to 1 when it receives the first character of a 
message, and clears it to when the end of the message is reached. RXINPROG 
indicates that a receive operation is in progress. 
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Receiver Operation: Application 

In response to the RXDONE signal, the application checks RXERROR and reads the 
number of characters received from RXCOUNT. Then it stores the address of a new, 
empty buffer in RXNXTBUF and clears RXREADY. 
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PILEUP Errors 

Notice that the receiver sets itself up to receive the next message immediately after 
the preceding message is received. Thus, the application has one entire message 
time to respond to the RXDONE signal. If for some reason the application fails to 
absorb the preceding message when the next message is received, the driver will 
find that the RXREADY flag is still set to 1. This situation is called a message PILEUP 
error. 

To handle a PILEUP error, the driver increments the PILEUP error counter, clears 
RXINDEX to zero, and begins receiving the next message. The error is not reported 
in RXERROR because this field (and RXCOUNT) must not be changed once the 
RXDONE signal has been sent. The application will learn about the PILEUP error 
when it receives an out-of-sequence message (due to dropping one or more 
messages) or when it scans the error counters directly. 
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Some applications require a response to a "line idle" condition. An idle condition 
occurs when eight or more consecutive 1 bits are detected on the line. Usually, the 
flag idle option is selected, in which the transmitter sends continuous flag patterns 
(01 1 1 1 1 10) between frames, preventing an idle condition. Detecting an idle 
condition may indicate that the transmitting station is out of order. 

The driver (with the hardware in use) automatically maintains a flag in the 

InterfaceRec called RXACTIVE. This flag is set to 1 whenever the line is active and 

when it is idle. Each time the RXACTIVE flag changes value, the driver sends the 

ACTCHG signal to the application. Using this mechanism, the application can 

maintain a time-out on the length of time the line is idle. If the idle condition is 

irrelevant to a given application, that application may ignore the RXACTIVE flag n 

and the ACTCHG signals. J 

Start-up Considerations for Transmitter °1 

On the transmit side, the application does nothing special before starting 

synchronous operation. Zeroing the InterfaceRec clears the transmitter's control H 

fields, causing it to wait until the application has a message to transmit. J 
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Transmitter Operation: Application 

When the application has a message to transmit, it stores the address of the buffer 
containing the message in the field TXBUF. It stores the number of characters in the 
message (not the total size of the buffer) in TXCOUNT and sets TXREADY to 1 . To 
make sure the driver notices that the application has given it a message to transmit, 
the application calls StartTx. 
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Transmitter Operation: Driver 

When the hardware transmitter is ready to begin transmitting another message, 
the driver clears TXREADY, setsTXINPROG, and begins transmitting the message. It 
usesTXINDEX to keep its place in the buffer. When message transmission is 
completed, the driver stores zero (or an error code) in TXERROR, clears TXINPROG, 
and sends the signal TXDONE to the application. (The use of the TXINPROG flag is 
explained later.) 
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Upon receiving the TXDONE signal, the application checks TXERROR, then sets up 
the next message for transmission if there is one. The application should try to 
respond to the TXDONE signal as quickly as possible. This keeps the transmitter 
busy during periods of heavy data traffic. 
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Aborting Transmissions 

To prematurely abort a transmit operation (e.g., for a priority message), the 
application usesTXINPROG "transmission in progress" flag. 

The driver sets TXINPROG at the beginning of each transmission and clears it at the 
end of each transmission. During the transmission, the driver checks TXINPROG 
before transmitting each character. If TXINPROG is still 1, transmission continues; if 
the application has cleared TXINPROG to 0, the driver aborts the transmission. 
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For example, suppose the application has a higher-priority message to transmit, 
requiring the current transmission to be aborted. The application would clear 
TXINPROG, set up the new message for transmission, then set TXREADY and call 
StartTx. 
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The following situation is possible: the application decides to abort the current 
transmission, but before it clears TXINPROG the current transmission is completed 
normally. In this case, the driver would have already cleared TXINPROG at the end 
of message transmission and no abort would occur. 

Error Handling 

The error code fields, RXERROR and TXERROR, report the outcome of each receive 
and transmit operation, respectively. When a transmit or receive operation is 
completed, the synchronous driver sets the error field to zero if no error occurred, 
or to a non-zero error code if an error did occur. The driver also increments the 
error counter of the corresponding error code every time an error occurs, to provide 
a more permanent record of errors. There are separate error counters for the 
transmit side and the receive side. 

The RXERROR and TXERROR fields can only be used when an error occurs during a 
specific transmit or receive operation. The error counters record errors which occur 
both during and outside of transmit and receive operation. 



1 



36 



M$& 



• fSPI 






w 



pi 



ipn 



[PI 



$$? 



I 



Error Codes 

HSI provides for 20 error codes, numbered 1 through 20. (Code is used to indicate 
that no error occurred.) Six error codes, numbered 1 through 6, are defined by HSI 
The remaining 14 are reserved for future or specialized usel>y each application 
Chapter 3, on BISYNC operation, describes how the undefined error codes may be 
used. There is an error counter in the InterfaceRec for the 20 error codes for both 
transmit and receive, (40 altogether). 

The error conditions and their code numbers are: 

Hardware overrun/underrun. 

Abort sequence transmitted or received. 

Modem signal lost (DCD for receive side, CTS for transmit). 

Reception of next message completed before application 
processed previous message. 
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p 5. OVFLOW Incoming message overflowed buffer (RXLIMIT was less than 

message length). 



Incoming message has bad check sequence. 



Two fields, RXINTERR and TXINTERR, may be used by the synchronous driver to 
report internal errors. An internal error usually occurs when the driver is in the 
wrong operating mode (e.g., the driver may be in the end-of-message mode before 
the first character of a message has been received). 

HSI does not specify the format of the error codes stored in RXINTERR and 
TXINTERR, beyond stipulating that they be nonzero. A zero code indicates no error. 
Internal error should not occur; it indicates a programming error in the synchronous 
driver or a problem in the hardware. 

Modem Signal Usage 

HSI does not define specific modem signal usage, except for the signals RTS (Request 
To Send), CTS (Clear To Send), and DCD (Data Carrier Detect). Assuming the 
hardware being used supports them, these three signals are controlled or tested by 
the synchronous driver during the course of transmit and receive operations. The 
driver requires the presence of an active DCD signal before it validates received 
data. If DCD is not present or is lost during message reception, an error code is 
generated. 
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On the transmit side, the synchronous driver raises RTS each time it is ready to 
transmit a message, then it waits for CTS to go high before beginning message 
transmission. At the end of the message, it drops RTS. If CTS is lost during message 
transmission, an error code is generated. 

The application can program RTS high or low, just like any other modem signal that 
functions as an output. The state of RTS as outputted is the logical OR of the 
application's setting and the driver's control. It the application programs RTS low, 
the signal will be under the control of the driver, and will go high and low as 
messages are transmitted. If the application programs RTS high, it will be fixed 
high. In every case, however, the driver requires an active CTS signal for proper 
message transmission. 

In certain types of hardware, other modem signals (such as Data Set Ready, DSR) 
might be required in order for transmit and receive operations to occur. HSI does 
not address these signals. 
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.F CHAPTER 3-RECEIVING AND TRANSMITTING: BISYNC 

m BISYNC vs. SDLC/HDLC 

BISYNC operation is identical to SDLC/HDLC operation in many ways. The same 
mechanism is used to exchange buffers containing messages back and forth 
I between the synchronous driver and the application. All of the fields in the data 

I exchange interface section of the InterfaceRec work the same way for BISYNC mode 

as they do for SDLC/HDLC mode. Refer to Chapter 2, covering SDLC/HDLC operation, 
m for a complete discussion of the topics that are common to both BISYNC and 

SDLC/HDLC operation. This chapter points out the differences between the two 
modes of operation and covers topics that pertain only to BISYNC operation. 
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Block Format 

BISYNC messages are called blocks. Unlike SDLC/HDLC frames, which have a very 
well-defined and universally accepted format, BISYNC blocks come in many 
different forms. There is no universally accepted format for BISYNC blocks. For 
example, it is not possible to define a method for establishing the end of a BISYNC 
block that will work for every variation of the BISYNC protocol in use today. Thus, 
BISYNC operation is characterized by a greater reliance on the application to 
participate in the operation of the synchronous data link. 

A BISYNC block consists of a series of characters. Blocks always include one or more 
control characters and may also include data characters. Each block is preceded by a 
series of two or more synchronization (SYN) characters. The purpose of these 
characters is to lock the receiver into character synchronization. Blocks containing 
data characters usually also contain a Block Check Character (BCC) sequence, 
analogous to the SDLC/HDLC's Frame Check Sequence. Each block is stored in a 
separate buffer and cannot span buffer boundaries. The maximum buffer size is 
64K bytes. Eight bit characters are assumed, but any character set can be used. 
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All characters comprising the block, except for the opening SYN characters, are 
stored in the buffer. Any SYN characters appearing later in the block, as well as all 
other control, data, and block check characters, are stored in the buffer. 
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What the Synchronous Driver Provides 

The synchronous driver (with the hardware being used) automatically appends two 
opening SYN characters to transmitted blocks. The application may specify the 
particular 8-bit character which will serve as the SYN character. On the receive side, 
the opening SYN characters are detected but not stored in the buffer. The 
application processes block check characters, control characters, and idle SYN 
characters. The application also determines the end of the message being received. 

Per-character Processing 

In order to perform its functions, the application must get involved in the character- 
by-character processing of data. The two per-character service routines, TxCharProc 
and RxCharProc, are defined to enable this. The presence of per-character 
processing does not eliminate the data-buffering function of the driver. 
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The synchronous driver continues to transfer data between the buffers and the 
hardware, but in BISYNC modes, the driver lets the application "peek" at the data as 
it is transferred and give the driver special character-by-character processing 
instructions. 
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Synchronous Protocol Options for BISYNC 

The following are the synchronous protocol choices relevant to BISYNC mode: 

BSC To select BISYNC mode, this field is set to 1 . Some synchronous 

devices might not support BISYNC operation; in such cases, 
Preprocess would return the result code MODENS (Mode Not 
Supported). 

ADDRDET The driver ignores this field for BISYNC mode. 

SDLCADDR The driver ignores this field for BISYNC mode. 

BSCSYNC The application stores the desired SYN character in this field, 

(usually 32 hex for the EBCDIC character set or 1 6 hex for 
ASCII). 
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FLAGIDLE 



WRAP 



If Non-Return To Zero Inverted (NRZI) encoding and decoding 
is desired, this field should be set to 1 ; otherwise, this field is 
set to 0. 

If this field is set to 1, the transmitter sends continuous SYN 
characters when it has no data to transmit. If this field is set to 
0, the transmitter sends a continuous mark level (all ones). 
Notice that this choice is made only once during set-up for the 
synchronous session (before calling Preprocess). It is not 
possible to switch back and forth between mark idle and SYN 
idle in the middle of one session. 

Setting this field to 1 selects the hardware wrap option, if 
available. See Chapter 2 for a more complete discussion of the 
wrap option. 
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Receiver Operation 

The application and the synchronous driver go through the same sequence of 
events for BISYNC operation as described in Chapter 2 for SDLC/ HDLC operation. At 
the same time, however, per-character processing occurs. The driver calls 
RxCharProc just after it receives each character. Inside RxCharProc, the application 
has the opportunity to examine the stream of incoming characters and influence 
the driver's processing by selecting certain processing options. 

Unless instructed otherwise, the synchronous driver simply stores the character in 
the buffer and waits for the next character after control returns from RxCharProc. 
As an alternative, the application can select two select processing options on each 
received character: 

IGNORE Ignores the character just received. 

ENDMSG Treats character as the last character of the message and 

performs end-of-message processing. With this option, 
RxCharProc may return an error code to be associated with the 
message, otherwise the driver indicates no error. 
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Either or both processing options may be selected independently for each character. 
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The use of per-character processing to implement BISYNC communications is the 
application programmer s decision. HSI requires only that the ENDMSG option be 
selected at the proper time to terminate each received message. To do this, the 
application implements some sort of finite-state machine to follow the BISYNC 
protocol for each message that it receives. Each time RxCharProc is called, the 
application uses the character just received to advance the machine to a new state. 
When a terminal state is reached, the ENDMSG option is selected. 

With per-character processing, the application can also compute and check the 
block check character sequence at the end of each message, and return an error 
code with the ENDMSG option if the check sequence is bad. Other error conditions, 
such as BISYNC protocol violations, can be detected and reported making use of the 
undefined error codes. With the IGNORE option, the application can strip idle SYN 
characters and DLE (Data Link Escape) characters from transparent text. By 
stripping these characters from the data before it is stored in the buffer, the data 
need not be recopied to remove the characters later. 

Refer to Appendix B for a detailed description of how RxCharProc and TxCharProc 
are called, what parameters are passed to them, and what results they return. 
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Transmitter Operation 

Transmitter operation in BiSYNC mode is similar to SDLC/HDLC mode, with the 
addition of per-character processing. After the synchronous driver reads each 
character from the buffer, and before it transmits the character, the driver calls 
TxCharProc. Inside TxCharProc, the application can examine the stream of transmit 
data and select processing options. It no processing option is selected, the driver 
transmits the character normally. One of the two alternatives to this default 
processing may be selected: 






1. INSERT 



SUBST 



By selecting this option, the application can cause a specified 
character to be inserted in the message just before the 
character about to be transmitted. After transmitting the 
character, the driver calls TxCharProc again for the character 
that was to be transmitted previously. 

By selecting this option, the synchronous driver transmits a 
substitute character to replace the character about to be 
transmitted. After transmitting the substitute character, the 
driver proceeds to the next character in the buffer. 
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Per-character processing on the transmit side is not as critical to BISYNC link 
operation as it is on the receive side. HSI does not specify what or when processing 
P options must be selected. A BISYNC link may be run without using per-character 

processing on the transmit side, by storing the message in the buffer exactly as it is 
to be transmitted. 
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Some applications may choose to use per-character processing on the transmit side 
to process data as it goes out to the transmitter, rather than processing data in 
advance in the buffer. For example, the trailing block check character sequence can 
be computed inside TxCharProc and placed in the message on top of dummy, place- 
holder characters using the SUBST option. Also, idle SYN characters can be inserted 
at regular intervals into the message by tying TxCharProc into some kind of real- 
time clock service provided by the application. DLE characters can be inserted into 
transparent text where necessary via the INSERT option. Again, a finite-state 
machine is usually used to control TxCharProc, so that it chooses each processing 
option at the right time. 

Buffer Switching 

The open-ended nature of HSI, with regard to BISYNC operation, allows for creative 
application designs. For example, it may be advantageous in some applications to 
store control characters separately from data characters, the latter being stored in 
data buffers. TxCharProc or RxCharProc could be programmed to switcn the BUF, 
COUNT, and INDEX fields to point to different data sources as message transmission 
(or reception) progresses. 



For example, TXBUF can be set to point to a data area containing a fixed sequence 
of control characters. TXCOUNT can be set to the length of this sequence, or to 
some arbitrary high value. Under the control of a finite-state machine inside 
TxCharProc , the synchronous driver is allowed to transmit the control characters. 

I TXBUF, TXCOUNT, and TXINDEX then can be reset to point to a buffer containing 

the data portion of the message. To support this type of creative programming, the 

« driver does not hold the value of variables such as TXBUF, TXCOUNT, or TXINDEX in 

registers across calls to TxCharProc or RxCharProc. 

Modem Signal Usage 

Modem signals are used exactly as described in Chapter 2 for SDLC/HDLC mode. 



Error Handling 

BISYNC error handling is the same as that described for SDLC/HDLC, except that 
user-defined error codes may be returned from RxCharProc via the ENDMSG option. 



If RxCharProc fails to return the ENDMSG option for a given incoming message, a 
buffer overflow error (OVFLOW) will eventually be generated. 

ppi 4-5 



Aborting Transmission and Reception J 

HSI does not support an abort sequence for BISYNC mode. If an abort sequence is 

defined for the BISYNC protocol variant being used in a given application, it is 

detected by RxCharProc. The ENDMSG option is taken, and the ABORT error code is 

returned. On the transmit side, the synchronous driver responds to the application's 

clearing the TXINPROG flag the same as it does in SDLC/HDLC mode, except that no H 

abort sequence is sent. The transmitter simply reverts to its idle state (SYN idle or i 

mark idle). Transmission of the next message may begin immediately thereafter. 

Active/Idle Status Reporting 

This facility is not relevant to BISYNC mode. 

Finite State Machine Initialization 

It may be simpler in some applications for the finite state machines within 
RxCharProc and TxCharProc to automatically reset themselves to their initial states 
at the beginning of each message rather than having this action performed at 
another time (when the state machines detect end-of-message, for example). To do 
this, RxCharProc and TxCharProc should test the InterfaceRec fields RXINDEX and 
TXINDEX, respectively, each time they are called. If the field has the value 1, the 
state machine should reset itself then process the first character of the message. 
Otherwise, the character should be processed normally. 
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CHAPTER 4--TERMINATING SYNCHRONOUS OPERATION 

To terminate synchronous operation, the application calls EndSync. Inside EndSync, 
the synchronous driver shuts the device off, removes the interrupt service routine, 
and performs whatever other operations are necessary to terminate synchronous 
operation. 

Effect on Operations in Progress 

If transmit or receive operations are occurring when EndSync is called, the driver will 
abort them automatically. For transmit operations, an abort sequence is sent; for 
receive operations, the driver pretends to receive one. The appropriate signal, 
TXDONE or RXDONE, is sent with an ABORT error code. The signaling mechanism 
may be invoked during EndSync processing; it should be left intact on the 
application side until control returns from EndSync. 

Use of DelayProc 



Some synchronous devices require a time delay during their deactivation sequence. 

This time delay is obtained by the driver calling the DelayProc service routine. The 
p application may do whatever it wishes with the CPU during the delay interval, as 

[ long as it returns control when the interval expires. The use of DelayProc avoids the 

use of an idle loop inside the driver. DelayProc is called only during termination 
m processing, as the result of a call to EndSync. It may be usecf by some device drivers 

and not others. 
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Since the delay required by synchronous devices may differ, the synchronous driver 
passes the desired time delay as a parameter to DelayProc. The delay may vary from 
to 65535 milliseconds and should be timed as accurately as possible by the 
application using the timer services provided by the host operating system or 
programming language. However, the driver must not depend on this mechanism 
for extremely accurate delays. 
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Usually, DelayProc is used to time-out an event which occurs during termination. If 
DelayProc returns before the event occurs, the synchronous driver assumes that 
something is wrong and stops waiting for the event. If the event occurs before the 
time-out expires, the delay is no longer needed and DelayProc may return. A signal, 
DLYEND, is defined for use in this situation. 
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If DelayProc has been called to time-out an event within 3 seconds, and the event 
occurs after 1 second, the device hardware generates an interrupt which the 
synchronous driver services. The driver recognizes the event and sends a DLYEND 
signal to the application. At this point, interrupt servicing is completed and the 
application again has control of the CPU. In response to the DLYEND signal, the 
application causes DelayProc to return control immediately to the driver. 
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If a delay is not in progress when the DLYEND signal is received, the application may 
apply the signal to the next call of DelayProc, returning the call immediately. In 
fact, the DLYEND signal may set a flag which returns ail subsequent calls to 
DelayProc immediately. This flag should be reset before StartSync is called again. 
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Restarting Synchronous Operation 

By calling StartSync again, synchronous operation may be restarted after it has 
been terminated. The application should not call Preprocess again unless a new 
synchronous session (with a new set of parameters) is desired. Synchronous 
communications picks up where it left off when EndSync was called. Since most 
synchronous protocols have error detection and automatic request (ARQ) for re- 
transmission facilities, the service interrupt is not visible to the user except for a 
momentary pause in communications. An extended service interrupt, however, may 
result in a time-out by the other party and a termination of the call on that side. 
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Protection Against Race Conditions 

The synchronous driver routines EndSync, StartTx, and UpdateSigs have built-in 
protection against race conditions which might occur during termination. Since 
calls to these routines may be made from several different tasks running inside the 
application, improper calling sequences may occur during termination. 

For example, one task might call StartTx after another task called EndSync. Two 
separate tasks might decide to terminate synchronous operation, resulting in two 
consecutive calls to EndSync. Even though these situations are programming errors, 
they may be difficult to avoid in complex applications. 

A simple mechanism built into EndSync, StartTx, and UpdateSigs prevents these 
errors from occurring. The first call to EndSync sets an internal flag indicating that 
the driver is down. When this flag is set, a subsequent call to any of these three 
routines will result in no operation. The flag is reset the next time StartSync is 
called. 
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CHAPTER 5-SIGNALING MECHANISM 

Application and Synchronous Driver Processes 

The operation of the application and the synchronous driver may be considered two 
independent processes. Once synchronous operation begins, the synchronous 
driver runs independently from the application, getting control of the CPU in 
response to device interrupts. Exceptions occur when the application explicitly calls 
a driver routine, (either StartTx or UpdateSigs). The driver can be thought of as 
always taking control from the application at unpredictable times, leaving the 
application in a suspended state while the driver executes. 

When the driver completes all processing, it returns the CPU to the interrupted flow 
of control in the application. In a driver routine call, control is returned to the 
caller, but the application usually is unaware that anything happened 
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Need for Signaling Mechanism 

Some occasions during the execution of the synchronous driver require a reaction 
from the application. For example, if an incoming message has just been received, 
the application must attempt to process that message. If the driver simply returns 
control to the interrupted process, the application will continue as though no 
message was received. 

Clearly, a mechanism must be defined to permit the driver to occasionally 
communicate with the application. This mechanism would be invoiced when events 
occur within the driver, calling for the application to alter its flow of control. This is 
the role played by the signaling mechanism. 
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How the Synchronous Driver Sends Signals 

The signaling operation occurs just before the synchronous driver returns control to 
the interrupted process (or caller of StartTx or UpdateSigs). At this point, the 
driver's immediate processing needs have been satisfied, all interrupt conditions 
have been cleared, and the interrupt system has been re-enabled. 

Before returning control to the interrupted process, an extra step is inserted: the 
driver constructs a special signal word, indicating the signals it wants to issue, and 
calls SignalProc, one of the five service routines provided by the application. The 
signal word is passed as a parameter to SignalProc. 
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How the Application Responds 

Inside SignalProc, the application examines the signal word and reacts, based on the 
indicated signals. Sometimes all of the appropriate processing can be performed 
inside SignalProc. If a multitasking system is in use, SignalProc may activate one or 
more high-priority tasks to perform the processing. Eventually control returns to 
the synchronous driver from SignalProc and is then transferred back to the 
interrupted process. 
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Nested SignalProc Calls 

If a task activated by SignalProc has a higher priority than the one that was 
originally interrupted (which the multitasking system assumes is still in control), it 
may preempt the execution of SignalProc itself. In this situation the execution of 
SignalProc is suspended as long as it takes to execute the high-priority task. This 
task may in turn be preemptedby even higher-priority tasks. A relatively long 
period of time may, therefore, elapse between a call to SignalProc and the 
corresponding return. 

While SignalProc, or the tasks it activates, is executing, interrupts may occur 
resulting in new calls to SignalProc, even before control returns from the original 
call. These nested SignalProc calls may result in signals being processed out of 
order. This should cause no problem, since the signals do not interact with each 
other. 
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Because nested calls may occur, SignalProc must be reentrant, and process more 
important tasks (such as RXDONE and TXDONE) before less important ones. 
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The Signal Word 

Five possible signals are mapped to individual bits in the 16-bit signal word. For 
each signal the synchronous driver wishes to send, the corresponding bit is set to 1 ; 
all other bits are set to 0. After constructing the signal word, the driver passes it as a 
parameter to SignalProc. Thus, any combination of the five signals can be sent in 
one operation. Appendix B describes in detail how SignalProc is called, including 
the format of the signal word. 

The five possible signals are as follows: 

Indicates that a receive operation is complete. 

Indicates that a transmit operation is complete. 

Indicates that the RXACTIVE flag has changed state. 

Indicates that one of the modem signals in MODSIGS has 
changed state. 

Indicates that DelayProc may now return, even if the delay 
period has not expired. 
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P Start-up and Shutdown Considerations 

The application must be ready to receive signals when it calls StartSync. Signals may 
come at any point until control returns from EndSync. Therefore, the application 
leaves its sicmal handlina mechanism intact until control ratnmdrnm c n /K un /» 
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leaves its signal handling mechanism intact until control returns from EndSync. 



Special Considerations 



Some multi-tasking systems require that all interrupt service routines be installed 
using a special system call. This gives the multi-tasking system a chance to surround 
the user s interrupt service routine with its own entry and exit code needed to 
support multi-tasking operation. Since HSI specifies that the synchronous driver 
install its own interrupt service routine directly, the special entry/exit code is not 
executed for interrupts from the synchronous device. 

Most interrupts simply transfer one byte of data and return, but problems may arise 
when interrupts result in a call to SignalProc. If SignalProc makes a system call to 
wake up a task, post an event, etc., the system will believe that this call was made 
by the interrupted process since the special interrupt entry code was not executed. 
This is not necessarily a problem; however, it can lead to deep stack nesting if 
SignalProc calls are made faster than they can be processed. 

m A solution to this problem is to install a second, dummy interrupt service routine 

with the aid of the system call, and invoke it from SignalProc by means of a software 
interrupt mechanism. By making the multi-tasking calls inside this second interrupt 
service routine, they will be properly preceded and followed by the system's 
interrupt entry/exit code. 
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CHAPTER 6--M0DEM SIGNALS 



Modem Signal Mapping 



The InterfaceRec field, MODSIGS, contains the current state of the modem signals, 
both inputs and outputs. MODSIGS is a 16-bit word, providing for 16 of the 25 
possible RS-232 signals. 
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The nine signals which aren't provided for are the data, clock, and ground signals; 
any signal that the application might want should be there, as long as the signal is 
actually supported by the hardware. 

All of the commonly used modem signals are provided for: RTS (pin 4), CTS (pin 5), 
DCD (pin 8), DSR (pin 6), DTR (pin 20), Ring Indicate (pin 22),and Rate Select (pin 23). 
In addition, signals that have been redefined for special purposes by particular 
vendors are present, such as IBM's Test (pin 18), Test Indicate (pin 25), and Select 
Standby (pin 1 1). 
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Components of Modem Signal Support 

The complete modem signal support package consists of three bit-mapped fields in 
the InterfaceRec: MODSIGS, MODSET, and MODSUP, (plus the driver procedure 
UpdateSigs). MODSIGS and MODSUP are set by the synchronous driver and read by 
the application; MODSET is set by the application and read by the driver. 
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Reading the Modem Signals 

The synchronous driver maintains MODSIGS to reflect the current status of the 
hardware-supported modem signals. Whether a signal functions as an input or an 
output, the corresponding bit in MODSIGS is a 1 if that signal is asserted, and a if it 
is not. Any time a bit in MODSIGS changes state, the driver sends the signal, 
SIGCHG, to the application. 
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Controlling Output Modem Signals 

To control modem signals that function as outputs, the application stores its modem 
signal settings in MODSET, then calls UpdateSigs. 
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Inside UpdateSigs the synchronous driver copies the bit settings in MODSET to the 
actual signal outputs. Bits in MODSET corresponding to input signals are ignored. 
At the same time, the driver updates MODSIGS to reflect the new settings of the 
output signals, and sends a SIGCHG if necessary. 

Supported vs. Unsupported Modem Signals 

Because all hardware devices do not support the same subset of the modem signals, 
the application must be informed as to which signals are supported in the particular 
hardware device being used. The InterfaceRec field MODSUP performs this 
function. As part of the processing performed by Preprocess, the driver sets each bit 
in MODSUP to one that corresponds to a supported modem signal. A zero bit 
indicates that the corresponding signal is not supported. The unsupported signals 
are always reported as zeros in MODSIGS. The driver ignores the bits in MODSET 
corresponding to unsupported signals. 
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Input vs. Output Modem Signals 

HSI does not specify which signals are inputs or outputs, except for RTS, CTS, and 
DCD. Where these signals are supported, CTS and DCD are always inputs and RTS is 
always an output. Chapter 2 describes how these three signals are used to regulate 
transmit and receive operations. 

Updating Modem Signals Updated? 

Many hardware devices generate interrupts when a modem signal changes state. 
Thereby, the synchronous driver can automatically track the status of these signals 
in the MODSIGS field and generate SIGCHG signals as necessary. HSI does not 
require this automatic updating for all signals, since some hardware devices do not 
provide interrupts on modem signal changes. To make sure that MODSIGS reflects 
the current status of all supported modem signals, the application periodically calls 
UpdateSigs. 

UpdateSigs causes the synchronous driver to read the current status of the input 
signals, copy the settings in MODSET to the output signals, and construct a new 
MODSIGS word reflecting the current state of all signals. It also issues the SIGCHG 
signal if the new MODSIGS is different from the previous one. 
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Calling UpdateSigs updates the signals as soon as possible, but not always 
immediately. Some devices have states in which the modem signal registers are 
inaccessible. In such cases the modem signals are actually updated some time after 
control returns from UpdateSigs. 
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Start-up and Shutdown Considerations 

UpdateSigs is automatically called by the synchronous driver when synchronous 
operation is being started. The driver constructs a new MODSIGS word as usual and, 
before storing it in the InterfaceRec, compares it to the value of MODSIGS already 
there, sending a SIGCHG signal if they differ. When the driver terminates, MODSIGS 
is left the same as its last update. These features allow for smooth transitions into 
and out of synchronous driver control. 

If the application has an estimate of the status of the modem signals, it sets 
MODSIGS to reflect this estimate before calling StartSyncfor the first time. It also 
sets MODSETto reflect the desired settings of the output modem signals. 
Subsequent calls to StartSync (following EndSync calls) are made without changing 
MODSIGS, unless the application has additional knowledge of the status of the 
modem signals from some other source. 

When StartSync is called, the driver automatically makes any necessary corrections 
to MODSIGS to reflect the actual status of the modem signals, informing the 
application when necessary via the SIGCHG signal. 
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Programming with Modem Signals 

A number of functions can be programmed into the application making use of 
modem signal support. For example, the delay between the time RTS is raised and 
CTS goes high can be measured; an error message can be printed if the delay 
exceeds an established time-out value. 
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Some devices have on-line/off-line states under the control of DTR; the application 
can control DTR to place these types of devices in the desired state. Devices may 
have other states (such as the Link Problem Determination Aid (LPDA) facility in 
some IBM modems) that the application can invoke by manipulating other modem 
signals. In all cases, however, the application first checks MODSUP to make sure 
that the modem signals it will be using are actually supported by the hardware. 
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CHAPTER 7-TRACE FACILITY 
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What is the Trace Facility? 

HSI defines a simple trace facility that system developers may use to help them 
debug driver code. The trace facility lets the driver send trace data to the 
application, which is then responsible for displaying or printing it. 
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How the Trace Facility is Used 

A trace macro is usually defined in the synchronous driver source program, which 
the programmer may code anywhere to obtain trace data. The trace data may be 
any 1 6-bit value, such as the contents of a CPU register or memory location. Paired 
with the trace data is a 2-character mnemonic code, called the trace message, that 
identifies the data. 

The trace macro generates a call instruction to the TraceProc service routine. The 
trace data and trace message are passed as parameters to TraceProc and the address 
of the InterfaceRec. Inside TraceProc, the application prints or displays the trace 
data and message, returning control to the driver as quickly as possible. 
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Driver 


















Call TraceProc 
( data, message ) 




























Print trace data 
Print trace message 
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The trace facility is an optional feature of HSI to be used for debug purposes only. 
All trace macros should be removed from driver code that will be put in a 
production environment. 
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APPENDIX A-INTERFACE RECORD LAYOUT 
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General Information 

All numerical values in the InterfaceRec are unsigned binary. Two-byte values and 
addresses are stored in the customary format for the machine being used. For the 
IBM PC, two-byte values are stored least-significant byte first; addresses take the 
form segment: offset and are stored offset first. 

In this document, the least significant (right-most) bit is bit 0. 
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Explanation of Columns 



Offset 
Field name 
Bytes 
Set by 



Byte offset of field from beginning of InterfaceRec. 
Name this document uses to refer to field. 
Size of field, in bytes. 



" A " 

n 

H 



A" means application sets field and driver reads it; 
D" means driver sets field and application reads it; 
D/A" means field is set and read by both driver and 
application. 

Note: There may be unusual circumstances, described in this 
document, in which the "Set by" information provided here is 
violated. 



Description Comments describing use of field. 
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Section 1 -Device identification 



Offset Bytes Description 

Field : Set 
name by 



STRING 100 D/A Used in conjunction with the RECALL facility of 

Preprocess, this 100-character buffer is used to store a 
character string that the synchronous driver wishes to 
pass to an alternate driver, and to receive the reply 
string from the alternate driver. 



100DEVQUAL 2 A 



102 IOPORT 



104 INTVEC 



2 A 



2 A 



Device qualifier used to assist Preprocess in device 
identification. 

For some choices of DEVQUAL, the application must 
store the device I/O port address here. 

For some choices of DEVQUAL, the application must 
store the device interrupt vector number here. 



1 



"i 






Section 2-Synchronous Parameter Selection 

Offset 

Field ' : 

by 



f™a 



Field 
name 



Bytes Description 

Set 



106 BSC 1 A 

107 ADDRDET 1 A 

108 SDLCADDR 1 A 

109 BSCSYNC 1 A 

110 NRZI 1 A 

111 FLAGIDLE 1 A 



112 WRAP 



113 



1 A 



1 selects BISYNC mode; selects SDLC/HDLC mode. 

1 enables the SDLC/HDLC address detect option; 

disables this option. 

If the SDLC/HDLC address detect option is enabled, the 
desired station address is stored here. 

In BISYNC mode, the desired SYN character is stored 
here. 

1 selects NRZI encoding and decoding; selects NRZ. 

1 specifies that the transmitter will send continuous 
flags (for SDLC/HDLC mode) or SYN characters (for 
BISYNC mode) when idle; specifies that a continuous 
mark level will be sent. 

1 enables the wrap option if it is available; disables 
this option. 

Reserved for future parameters. 
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Section 3-Data Exchange Interface 



Offset 



Field 
name 



Bytes Description 

: Set 



by 



** 



RECEIVE SIDE 



** 



122 RXACTIVE 1 D 

123 RXREADY 1 D/A 

124 RXINPROG 1 D 

125 1 

126 RXERROR 2 D 

128 RXCOUNT 2 D 

130 RXINDEX 2 D 

132 RXBUFSIZ 2 A 

134 RXBUF 4 A 

138 RXNXTBUF 4 A 

142 RXINTERR 2 D 



1 means the data link is active; means it is idle. 

Driver sets to 1 when receive operation ends. 
Application clears to after picking up message. 

Driver sets to 1 when receive operation begins and 
clears to when operation is completed. 

This byte is not used. 

After receive operation, driver stores error code here 
(or if no error). 

After receive operation, driver stores number of 
characters received here. 

Driver uses this field to mark place in buffer for next 
character. 

Application stores size of receive buffer here. 

Application stores address of receive buffer here. 

Application stores address of next receive buffer here. 

Driver may store any internal error code here, 
otherwise this field is 0. 



144 RXERRCNT 40 D Array of 20 error counters for receive side. 
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Offset 



Field 
name 



Bytes Description 

Set 



by 



** 



TRANSMIT SIDE 



** 



184 TXREADY 1 D/A 

185 TXINPROG 1 D 

186 TXERROR 2 D 

188 TXINDEX 2 D 

190 TXCOUNT 2 A 

192 TXBUF 4 A 

196 TXINTERR 2 D 

198 TXERRCNT 40 D 

238 MODSIGS 2 D 

240 MODSET 2 A 

242 MODSUP 2 D 



Application sets to 1 when transmit buffer is ready; 
driver clears to when transmit operation begins. 

Driver sets to 1 when transmit operation begins and 
clears to when operation is completed. 

After transmit operation, driver stores error code here 
(or if no error). 

Driver uses this field to mark place in buffer to fetch 
next character. 

Application stores size of transmit message here. 

Application stores address of transmit buffer here. 

Driver may store any internal error code here, 
otherwise this field is 0. 

Array of 20 error counters for transmit side. 

** MODEM SIGNALS ** 

Current status of all modem signals. 

Desired state of output modem signals. 

Indicates which modem signals are supported by 
hardware. 



W 



ra 



n^a 



f*sa 



A-4 



TO 



Section 4-Service Routine Addresses 



Wl 



Offset 



sp 



sip 



r 



Field 
name 



Bytes 



Set 
by 



244 SIGPROC 4 A 

248 RXCHPROC 4 A 

252 TXCHPROC 4 A 

256 DLYPROC 4 A 

260 TRACEPRC 4 A 



Description 

Application stores address of SignalProc here. 
Application stores address of RxCharProc here. 
Application stores address of TxCharProc here. 
Application stores address of DelayProc here. 
Application stores address of TraceProc here. 
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Section 5-Reserved Areas 



Offset 



Field 
name 



Bytes 



Set 
by 



Description 



sp 



264 APPLAREA 48 A Reserved for application to use as it wishes. 
312 DRIVAREA 48 D Reserved for driver's internal use. 

The total size of the InterfaceRec is 360 bytes. 
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APPENDIX B- PROCEDURE CALLING CONVENTIONS 
FOR THE IBM PC ENVIRONMENT 



Other Environments 

This appendix describes how the driver routines and service routines are called in 
the IBM PC environment. It explains what parameters are passed, how they are 
passed, and how the CPU registers are affected. For non-IBM PC environments, the 
same parameters are passed to each subroutine, but the detailed calling 
conventions may differ. 



General Information 

All procedure calls and returns are of the "FAR" variety. All addresses are of the 
form segment: offset Data is pushed on the stack in the usual 8086 manner 
(segment first, etc.). The remark "All registers = garbage" is made in reference to a 
subroutine call does not apply to registers such as CS, IP, SS, and SP. 

The caller is to remove parameters from the stack after control returns from a 
routine call. 



Enabling and Disabling Interrupts 

p Interrupts may be disabled temporarily inside the driver routines to protect critical 

code sections. They are not blindly reenabled after the critical section, but rather 

1 are restored to the enabled/disabled state prevailing when the driver routine was 

called. 

With the exception of RxCharProc and TxCharProc, which are always called with 
interrupts disabled, the other service routines are usually called with interrupts 
m enabled. Calls with interrupts disabled would only occur as a consequence of the 

application's calling a driver routine with interrupts disabled. 
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Linkage Considerations 

The application needs to know the addresses of the five driver routines. HSI does 
not specify how this is accomplished, but two techniques are suggested : 

1 . Combine the driver and application source programs; compile/assemble them 
together and link edit in the usual manner. 



2. Provide a table of entry points at the beginning of the driver code segment. H 

] 



The driver obtains the addresses of the five service routines from the fields defined 
for this purpose in the InterfaceRec. 
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Explanation of Headings 

Entry: Conditions that are true before the subroutine is called. 

Exit: Conditions that are true after the subroutine returns. 

Driver Routines 

1. Preprocess 

Entry: Address of InterfaceRec pushed on stack 

Exit: DS, SI, Dl, BP = unchanged 
AX s result code 
BX = result code 
All other registers = garbage 

Result codes: 0--OK 

1 - RECALL -d 

2 - BADQUAL 

3 - BADCALL 
4-MODENS 
5--WRAPNS 
6-METHDNS 

2. StartSync 

Entry: Address of InterfaceRec pushed on stack 

Exit: DS, SI, Dl, BP = unchanged | 

All other registers = garbage 

3. EndSync 
Entry: Address of InterfaceRec pushed on stack 

Exit: DS, SI, Dl, BP = unchanged 

All other registers = garbage 

B-2 
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4. StartTx 

Entry: Address of InterfaceRec pushed on stack 

Exit: DS,SI, DI,BP = unchanged 

All other registers = garbage 

5. UpdateSigs 

Entry: Address of InterfaceRec pushed on stack 

Exit: DS, SI, Dl, BP = unchanged 

All other registers = garbage 

Service Routines 

1. SignalProc 



Entry: Address of InterfaceRec pushed on stack (first) 
Signal word pushed on stack (second) 
m DS = DS value stored by synchronous driver 

when StartSync last entered. 

m Exit: All registers = garbage 

Signal bits: BitO-RXDONE 
Bit1-TXDONE 



2. RxCharProc 



Bit2-ACTCHG 

Bit3-SIGCHG 

Bit4--DLYEND 

Bits 5 through 7 are ignored. 



Entry: DS:SI = address of InterfaceRec 
AL s character just received 

Exit: DS, SI, CX, DX, BP = unchanged 

BH ■ option bits (set bit to 1 to select that option) 
BL s error code or zero (for ENDMSG option) 
All other registers = garbage 



Option bits: Bit 0- IGNORE 

"■ Bit 1 - ENDMSG 

Bits 2 through 7 are ignored 



TxCharProc 

Entry: DS:SI = address of InterfaceRec 

AL = character about to be transmitted 
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Exit: DS, SI, AL, CX, DX, BP = unchanged 

BH = option bits (set bit to 1 to select that option) 

BL = specified character (for INSERT and SUBST options) 

All other registers = garbage 

Option bits: Bit 0-- INSERT 
Bit 1 -SUBST 
Bits 2 through 7 are ignored 

4. DelayProc 

Entry: Address of InterfaceRec pushed on stack (first). ' 
Delay interval in milliseconds pushed on stack (second). 

DS s DS value stored by synchronous driver r ~i 

when StartSync last entered. | 

Exit: All registers = garbage ^ 

5. TraceProc ' 

Entry: Address of InterfaceRec pushed on stack (first). "] 

1 6-bit trace data word pushed on stack (second). I 
2 -character trace message word pushed on stack (third). 

DS = DS value stored by synchronous driver H 



when StartSync last entered 
Exit: All registers = garbage 
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APPENDIX C-RESERVED DEVICE QUALIFIERS 



The following device qualifiers are reserved for use with HSD: 
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DEVQUAL «0. 



Indicates that the device has an asynchronous channel at a 
nonstandard address. The application stores the I/O port 
address and interrupt vector number in IOPORT and INTVEC, 
respectively. The driver queries the device for further 
identification by sending it AT commands via the RECALL 
facility of Preprocess. 



ipi 



DEVQUAL =1. 



Same as DEVQUAL s o, but the asynchronous channel is at the 
standard address for COM 1 . The driver sets IOPORT to 3F8H 
and INTVEC to 4. 






m\ 



DEVQUAL = 2. 



Same as DEVQUAL = 0, but the asynchronous channel is at the 
standard address for COM2. The driver sets IOPORT to 2F8H 
and INTVEC to 3. 



iup 



DEVQUAL a 3. 



Indicates that the device is an IBM SDLC Communications 
Adapter. The driver sets IOPORT to 388H and INTVEC to 3. 



rap 



NOTE: Software developers may register additional values of DEVQUAL for 
inclusion in this Appendix by calling Hayes Customer Service (404-441-1617). This 
service is extended to licensees of HSD only. Hayes Customer Service personnel are 
available from 8 a.m. to 8 p.m. EST Monday through Friday. 
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5) Hayes 



Hayes Microcomputer Products. Inc. 

705 Westech Drive. Norcross. Georgia }0i)92 

Telephone (4041 449-8791 Telex 703500 HAYES USA 

mailing address: 

RO, Box 105203. Atlanta. Georgia 3034& 



Dear Developer: 

Thank you for your interest in the Hayes Synchronous Interface (HSI) and the Hayes 
Synchronous Driver (HSD). 

Enclosed is your copy of: 

1. Technical References: Hayes Synchronous Interface for Applications Software. 

2. Two contracts for licensing the Hayes Synchronous Driver. 

3. A return envelope for licensing the Hayes Synchronous Driver. 

Should you desire to use the Hayes Synchronous Driver, you will need to sign both 
copies of the license agreement in order to receive the actual code that constitutes the 
Hayes Synchronous Driver. Once the agreement is executed, we will send you the 
Hayes Synchronous Driver technical reference guide with sample source code, and a 
disk containing the HSD source code. 

Please review the agreement carefully, and have an authorized representative of your 
company execute both copies as follows: 

1 . Sign at the bottom of the front page. 

2. Complete all information required on the back page. 

3. Initial the back page. 

When the agreements have been completed, please return both copies to us with your 
$250 license fee in the enclosed return envelope to the attention of the Contracts 
Administration. Once we have executed the agreement, we will send you the HSD 
material described above and a signed copy of the agreement 

Thank you for your interest in what we think is an important interface in the PC 
communications environment. If you have any other questions about this or our Hayes 
Developer Support Program please call me at (404) 449-8791 . 



Sincerely, 




Kathy Hamdy-Swink 
ISHV Relations Manager 






Q)Hayes°Microcomputer Products, Inc. 
Software Developer License Agreement 



Hayes Microcomputer Products, inc fHayt^ and the undenlgned iicenfee 
("IicenseO agree that the following tarns and cortditioiis shaE govern the 
license to licensee by Haves of the cnrimutersofhpMgpm|p*m« d»^^ ffn 
Exhibit A. as amended fay die parties from time to time (the "Software*) and 
associated documentation (the TVnimffitirton' 1 ). Jtor purposes of this Agree- 
ment unless otherwise indicated on Biliibit A. ti^tenn -Software 1 shafl mean 
me object code embodiment of such Software and all enhancements and 
updates thereof provided hereunder. 



1* license Hayes grants to Licensee a non-exdusive normansfaable, world 

wide license under Hayes* copyright to the Software and the DcKumentation (a) 

toi use, reproduce and distribute copies cf the Sciftwarem object cede ton c^ 

wtojncore<mflecliitottapfto 

cBsuftutBd by licensee to end users by safe ot license subject to the terms and 

fffflffttffm s of this Agreement (the •Application^ (b) to the extent that me 

Software is hotnsedmsourceoao^fbrnxtoreD^ 

far m ccrpcaation into the Application; and (c) to use the Doatmentatton 

mtemauty and to the extent authorized by Hayes m writing from time to time, 

to reprodu c e and dist ribute to end users capterfderigrat^ portions tflibf 

DoamMttUuc^ to the extent that the nmg^ 

tation for the Application licensee may not distribute the Software in source 

codefam. by itself or as marketed by Hayes and may not *«* tfm Hf or 

decompile any Software licensed in object code famLDuriig the term of this 

Apc mfftf T i rmr*e shafl^ 

the unmodified Software and the Documentation which may be released by 

Hayes, in its sole discretion, to all licensees of the Software. 

2. Ownarshipof Software. Hayes owns the Software and the Documentation 
the copyrights thereto and any conies &mstihama*dh*9m3nA*rHayimh****m 
authority to enter mto this Agreement and to giant to licensee a license to 
distribute the Software and DocumentattoaAnyinndififatinnsofmoSofbFare 
developed by licensee shall be the property of licensee, subject to the rights of 
Hayes under mis Agreement and applicable copyright laws. 

5. Term, this Agreement shall become effective upon the date accepted by 
Hayes, shall continue for a period of one year thereafter and shaE be automati- 
cally renewed for successive one year terms upon payment of the a " n ^ il license 
feeasprovidedtoSectkm4anduponexeqi^ 

to this Agreement which Haves mav spedfy from tiro* ta titw tmUff rariter 
terminated in accordance with Section 10 below. 

4. License Fee Upon execution of mis Agreement and prior m me commence- 
ment of am» annual renewal terra licensee shaD pay to Hay^ 

faith in Exhibit A Hayes reserves the right to change the license fee for the 
Software upon miry (Kf) days written notice prior to the commencement of any 
annual renewal term. 

5. Ucenstc Applications. licensee shall be entitled to incorporate the Software 
into any Application identified in Exhibit A I^n prior written notification to 
Haves.IicepseemayaddAppllf a tinni;^n»^^t 1 rv m l r ha rg< . **A*y *m«m mnA ' 
conditions of this Agreement shall apply to each such addition For the purpose 
of enabling Hayes to refer end uses to the appropriate persons mi assistance, 
licensee shall provide Hayes with information regarding available customer 
support for each Ap plic a tion , inriitdln g either a general technical description of 
or a comprehensive sales brochure fa; each Application upon licensee's 
distribution of the Application to a third party. 

6. Labeling. licensee shall not remove any copyrigknc^ioM or other proprie- 
tary legends contamed moron tte original Software 

include any Hayes copyright notice as it appears in or on the Software on all 
copies of and packaging for the Applications. Except as 
or otherwise permitted by law, licensee shall have no * fth t to use any of Hayes' 
trademarks or tradenames without Hayes* specific prior written consent licen- 
see shall cause the following warranty disclaimer to be printed conspicuously 
on the packaging for any Application 

THIS PACKAGE CONTAINS CERTAIN SOFTWARE COPYRIGHIED BY HAYES 
MICROCOMPUTER PRODUCTS. INC fHAYESn AND LICENSED TO LICENSEE 
HAYES MAKES NO EXPRESS OR IMPLIED WARRANTIES OF ANY KIND FOR 
THE SOFTWARE WHICH IS PROVIDED ON AN 'AS IS' BASIS. INCLUDING BUT 
NOT LIMITED TO. THE IMPLIED WARRANIIES OF MERCHANTABIIITY AND 
FTINESS FOR A PARTICULAR PURPOSE HAYES SHALL HAVE NO UABILTTY OF 
ANY KIND TO YOU. INCLUDING ANY LIABILITY FOR SPECIAL INDIRECT IN- 



GDENIAL OR CONSEQUENTIAL DAMAGES. 

7. Disclaimer of Warranty. THE SOFTWARE AND THE DOCUMENTATION 
AHBFKOW^TOICTNSEB-ASir 

THBRETOEssoaiMiiimiNajaDiNaaOT 

WARRANTIES OF MERCHANTABILITY AND FITNESS TOR A PAKHCDLAR 
PURPOSE HATES SHALL NOT BE LIABLE FOR ANY SPECIAL INDDEBCT. 
INCIDENTAL OR CONSEQUENTIAL DAMAGES. AND THE ENTEBBE* ASTO 
THE QUALITY AND PERFORMANCE OF THE SOFTWARE 6 ASSUMED BY 



t> TnrtfnnUl s iluu by Urtnue Except to the extent provided to Section 9 

^Itans^i^taae^ 

ctokiiie^Jtah^ 

damages incurred by Hayes tfizesuk of « arising dtrecoyevi^ 

licensee's use reproduction or distribution of the Software and the Docnmen- 

tatkm;c*(b)anyacl&omi 

obligations hereunder by J 



Elndgmiltolcmsya^ 

nannies* from any and all daima. losses. Iiabmti^#>» I w>no>« (»t^\A^ gP ^ f » n . 
ahkattatkKya'fecs) and damages incurred by licemge,bit£d4 > na A<w ' t fr a »tfit 
use or other distribution of the Software as authoring unte this Agreement 
infanges any United States patent copyright wtracW secret of any third pa^^ 
licensee shall promptly notify Hayes to wxmngctfary such daim, and m5vl4 
Hayes with all reasonable assistance in the defense or setdement thereof mtbe 
event of such a daim of infiingement Hayes shalL at its cation, (a) attempt to 
ditatofalicenseealiccsfletocaxa^ 

(b) modify or replace the Software with a r^f^nMr pmduct which is 
noninfringing or (cj rehmd the license fees prevkraly paid and terminate this 
Agreement This Section states licensee's sole and exclusive remedy for daims 
of infiingement In no event shall Haves' liability to Lkensee for such daims or 
far any other daim based on this Agreement exceed the license fees paid by 
licensee to Hayes hereunder: 

ia Termination. Hayes may terminate mis Agreement upon written notke if 

licensee breaches any of the terms and mndfflnm of tfa« Ap m~nm**M»A fcij f 

to remedy such breach within 30 days after written notification thereof 

T ermin a tio n shaE not adversely affect the rights of any third party who is a 

licensee of any Apphcato 

licensee shau promptly destroy or return to Hayes aE copies tfte 

the Documentation in its pos s es si on , custody or control shaE discontinue the 

niatangciccypiescrftheSc&ware.the 

ihall immediately cease distribution by sale, leare or otherwise of any copies of 

the Application then or thereafter in to possessicm> custody or control 

IX- Miscellaneous, This Agreement shall not be construed as creating an 
agency, partnership or any other farm of legal association between the parties. 
This Agreement constitutes the entire understanding between the parties 
enn r rrn i n g the subject matter hereof and may not be assigned by licensee. Any 
waiver or a me ndme nt of any provision of this Agreement shaE be effeettrconh 
if in writing and signed by both parties. Ncdun^ contained to this Agreement 
shall be construed as conferring upon licensee by implication, estoppel or 
otherwise, any license or other right under any patent This Agreement shall be 
governed by and construed in annnfanrrwgh the laws of the sate of Georgia, 

HATES VflCROCOMPUTKR PRODUCTS. INC 

B* . 



Tttfej. 



Acceptance Dates . 



LICENSEE* 



By:. 



Titles 



Date. 



085-1002 



Q)Hayes*Microcomputer Products, Inc. 

Exhibit A 

to 

Software Developer License Agreement 



1. licensee 

Name: 



Address 



* 4. licensee Contacb 

Name: 

TWe 



Phone 



2. Software licensed: 



HSD 



3. Annual license feet 



$250 



5. Description^) of Application^): 



■-•-EST 



■is- 



6. licensee's Commercial software Produces) 
Incorporating the AppIication(s){ 



GO Hayes'Microcomputer Products, Inc. 
Software Developer License Agreement 



Hayes Mioccornputer Products. Inc. ("Hayes*) and the undersigned licensee 
(licensee") agree that the following tams arvi coixteons shafl govern the 
license to licensee by Hayes of the computer software programs designated on 
M>to/> s amended by the parties hem time to time (the •Software") and 
s»oda ted documentation (the l>ccumenrasjan"). Ear purposes of this Agree- 
ment urusodierwire indicated an sadn^ 

die object code embodiment of such Software and all enhancement! and 
updates thereof provided hereunder. 



L license. Hayes grants to licensee a non-exduitvc, untransferable, worid 

wide license under Hayes' copyright <o the Software andtheDocumentattan(a) 

touseiepioduccafiddlialbu^ 

i<^ tacospoatjed inm an apejictfm 

attributed by licensee to end utm by sak or bceriresubjea to the ternary! 

£5™™ of this Agreement (the Mpp!icatian*> (b) to the oust that the 

8nwareialiceoae4tofc«EceoDe^ioan.tosep»duoei 

fa sn eoepoaBon Into the Application: and (c) tD we the 

totcmauy sod to the extent authorized by Hayes In wifttng from nme to time, 

to reproduce and distribute to end uses copies cfdetignat^podlona of the 

Documentation to the enem that th# — m» fr liwiP i p^ fit f d Jnto mf T ^^' " ff 1 **^ 

tatkm fa the Application. licensee may not cUstrihrte the Software in source 

CPdefam. by Itself or « nmfcrtNi hy Sfay« »™l ™«y ~^ A^^kU ^ 

decompfle any Software hcensed in bbjaet «A form nurfng th» t**™ *f thu 

AgreeiueuL licensee shall be entitled to receive enhancements and updates of 

the unmodified Software and the r^^wrm***^ ^r^h may ht irhwd by 

Hayes* in ns sole discretion, to aS licensees of the Software. 

I> Ownership of Software. Hayes wmt th» Saftwm+mnA fa+ T\nnif*—**fl m 



authority to enter into this Agreement and to giant to ! if * TTfrr a fen tse to 
distribute the Software and Donimrntitfoa Any mndiftratlnns of die Software 
developed by licensee shall be the psc^ertyciIicensee.sub]eatoureilghrsof 
Hayes under this Agreement and applicable copyright taws. 



9. Term Ibis Agreement shall become effective upon the date accepted by 
Hayes, shall continue fa a period of one year thereafter attdshaD be automat 



fa as prcMded in Se<tion4andupcm execution^ 

to this Agreement which Hayes may specify from time to time, unless earlier 

terminated in accordance with Section 10 below. 

4. license Fee. Upon execution of this Agreement and prta to die cotrunexice» 
mentof any annual renewal term. licensee shall pay to Hayes the amount set 
forth in Exhibit A. Hayes reserves the light to change die license fee fa die 
Software upon thnvflcn davs wria^iiflti^pT^mtfc^ rn^^^^^ ^,^ 
annual renewal term. 

S.UceaseeA&ltetlofi*. licensee shtf 

tatoanyAppucViraideBtifWta 

Hayes. Licensee may add Applications at no additicmaldiaigt and the terms and 

conditions ci this Agreement shall apply to each such addrtknxFc* the purpose 

of enabling Hayes to refer end uses to die appropriate pcrscsu fa assistance, 

licensee shall provide Hayes with infamatJon regarding available customer 

support fa each Application including either a general technical 

or a comprehensive sales brochure sol each Application yp pg licensees 

distribution of the Application to a third party. 

6. Labeling. licensee shall not remove arrvccyyiightpotifMmrtK^p^^ 
tary legends contained in or on the origmal Software, and shal reproduce and 
include any Hayes copyright notice as it appears in or on the Software on all 
copies of and iw rlr agin g fa the Applications. Except at ** (nnh in tJM« Sr ^^n 
or otherwise permitted by law, licensee shall have no right to use any of Hayes' 
trademarks or tradenames without Hayes' specific prior written consent licen- 
see shall cause the following warranty disclaimer to be printed conspicuously 
on the packaging for any Application: 

THIS PACK AGE CO NTAINS CERTAIN SOFTWARE COPYRIGHTED BY HAYES 
MICROCOMPUTER PRODUCTS. INC fHATESO AND LICENSED TO UCENSEL 
HAYES MAKES NO EXPRESS OR IMPLIED WARRANTIES OF ANY KIND FOR 
THE SO FTWAR E WHICH IS PROVIDED ON AN 'AS IT BASIS. INCLUDING BUT 
NOTUMniD TO. THE IMPLIED WARRANIIES OF MERCHANTABILITY AND 
FIINESS FOR A PARTICULAR PURPOSE HAYES SHALL HAVE NO LIABILITY OF 
ANY KIND TO YOU. INCLUDING ANY LIABILITY FOR SPECIAL INDIRECT IN- 



QDENXAL OR CONSEQUENTIAL DAMAGES 



7. Disclaimer of Waaanty. 1HB SOFTWARE AND THE DOCDMENIADON 

AiBFRoviDroToijaNsm^ 

!M»B glBSS QEIMPLBD.lWQiIDgW&BOT 

WARRAN IIES OF MERCBANTAEILnT AND FIINESS FOR A PAmCQLAR 

PURPOSE HAYES SHALL NOT BE UABLB FOR ANY SPECIAL mnT FT 

INQDENIALOlOGIgRgmmAL PAMAf^ ^ppT ^ 

^OTAIXTt AND PERFORMANCE OF THE SOFTWARE E> ASSUMED BY 



Except to the 



psofidedin 



don taOaaaity Haya ad UdJthanfea bom » old 



a. 

Wow. 



dm^ laM HtdbyHiy« M»n^ofcc«hh»dteafly«liiilliiiilj BwiW 
s use, rep tub a t km or distnhutioo of the Soft wa re and the I 
r(b)anyi 




m by Hayes. Hayes shall lndmmlfy Iicenacc and hold ft 

harmless ftom any ajd«BAttMlMM^ ltoM4f<^^^^ 

isrectrodief djstrihuMmi^tiwgMhi^ 

infringes any United Slates patimt copyright wtracW seem 

licensee shall piompdy notify Hayes to writirigctf airy such daim sad rxovide 

Hayes with ail r ra s nTiibTrtssliTinrr in the defenreeg se * ^ ™"*~^ fnlht 
event of such a daim of infilngement HayesshaILatirscfti0a(a)a8exi»tto 
ctofafalicensceallegMgtnmtfait^ 

(b) modify or replace die Software with a cimmarable product which ■ 
nnninfanglTU^ eg (c) refund the license fas pi ev 

Agreement This Section states licensee's scflc and exclusive t g m edfr fa dahns 
of rnfhngrmmt InnoeveptthanHave^hihllitvmTi^^^l^ ^^^^^ ^ 
fa any other daim based on this Agremt^ixr^^ hrr^ fajrM}- 
licensee to Hayes hereunder. 

iftT imntnartiin Hayx may tmwiitm» **\ f A f rfrmc m uptmwiitnanotiixif 

licensee breaches any of the terms and condttlcutstfdris Agreement asadftus 

to remedy such breach within 50 days after written ~*ft— ^ feseot 

T rrmin a tinn shall not adversely affect the lights of any third party who is a 

licensee of any Application at the tone of trrmtrattnn Opon ttotoattoa 

licensee shaSpiompdy destroy or return to Hayes aJl copies of the Softwareand 

dtcDocunrenta^ionfarta pos s fs si oa 

nuking of copies of the Software, the DocurnentaticmanddreAi^licantesand 

shaflirninediatdy cease distnlnrto 

the Application then or thereafter in its possession custoc^ a eon&ol 

1L Miscellaneous. This Agreement shall not be construed as creating an 
agency, partnenhip or any other form of legal assertion between the parties. 
This Agreement crms otutes die entire understanding between die parties 
concerning the subject matter hereof and rnay not be assigned by Lfcensee. Any 
waiver oramrnrimfflt of an? provision of this Afrreement shall b^gff^tt^^nW 
If in witting and signed by both parties. Nothing cctniained to this Agreement 
fhaR be construed as conferring upon licensee by irru>licaiicm. estoppel or 
otherwise, any license mc^i^m^*nvr*tFniLT^A£T~*»mrt *u*n i~ 
governed by and construed in accordance with the laws cfthe sate of Georgia. 

HATKS MXaOCOMPOlSRFlODUClX INC 

By, _ 



«tla. 



Acceptance Dates . 



UCENSEEi. 
By: 



TtUei. 



Date. 



085*1002 



Q)Hayes*Microcomputer Products, Inc. 

Exhibit A 

to 

Software Developer license Agreement 



l.Licenseei 

Name! 



4. Licensee Contacfc 



Bfle. 



Phone, 



2. Software Licensed: 



BSD 



5. Descriptton(s) of Application^ 



V« f *f 



3. Annual License fee: 



$250 



.'.•»■-*«« ■ 



6. Licensee's Commercial software Produces) 
Incorporating the Application(s)t 



(J) Hayes 



Hayes Microcomputer Products. Inc. 
PO Box 105203 Atlanta Georgia J054S 



HAYES MICROCOMPUTER PRODUCTS INC. 

I. BOX 105203 
ATLANTA, GA 30348 
At t n s Con t r ac t s Ad m i n i st rati on 



